This design doesn't account for all of requirements:

1. As the issue described, we need to provide the rate limit information for: "submitting weights, registering networks, and staking/unstaking (among others)", not all of these are exposed

2. The following concern from the issue is not addressed either: "But this would be difficult if any changes are made on the chain-side later-on and would involve a level of coupling." We need to provide a consistent rate limit information across all rate-limited items. This is just a suggestion made for example, but it could be designed as follows:

• Requests remaining this interval
• Total requests allowed per interval
• Next interval start

Then for interval based limits like subnet registration it just fits the design and for cool-off type of limiting it can work as "remaining requests = 0" and "Next interval start = block when cool off period ends".

First of all, the client software needs a way to know:

1. If it is allowed to make a request now
2. If not, then how long does it need to wait

I've found that I forgot to add NetworkRateLimit, BTW.

As I saw it, the problem is that when you deal with limits you get the error and you need to figure out whether you are allowed to perform the request without getting error - without performing an actual transaction.

"submitting weights":

There is already API for getting weight limits: SubnetInfoRuntimeApi::get_subnet_hyperparams:

• min_allowed_weights
• max_weights_limit
• weights_rate_limit

"registering networks":

Regarding subnet registrations per block: SubnetInfoRuntimeApi::get_subnet_hyperparams::max_regs_per_block.

Couldn't find anything more related to network registration rate limits.

Staking/unstaking covered by two methods: RateLimitInfoRuntimeApi::get_rate_limits and
RateLimitInfoRuntimeApi::get_stakes_this_interval.

If the clients want to check whether they exceeded the quota, they check the number of stakes allowed during interval stakes and compare it to the stakes made during interval.

We can't cover all the cases and logic, but given this data clients can build the logic, which prevent from executing transactions.